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Abstract 

With the advent of wide security platforms able to 
express simultaneously all the policies comprising an 
organization's global security policy the problem of 
inconsistencies within security policies become harder 
and more relevant. 

We have defined a tool based on the CHR language 
which is able to detect several types of inconsisten- 
cies within and between security policies and other 
specifications, namely workflow specifications. 

Although the problem of security conflicts has been 
addressed by several authors, to our knowledge none 
has addressed the general problem of security incon- 
sistencies, on its several definitions and target speci- 
fications. 

1 Introduction 

Over the years several access control policies have 
been proposed in the literature. Although these poli- 
cies cover many different situations and types of infor- 
mation, they are often considered in isolation. Thus, 
they are not suitable for organizations with complex 
structures, that manage simultaneously several types 
of information, thus requiring the simultaneous use 
of different access control policies. Moreover, policies 
are often scattered over different environments, mak- 
ing understanding and managing of global policies 
much more difficult. 

Recently there has been a considerable interest in 
environments that support multiple and complex ac- 



cess control policies, || [Tl], |l6|, |l3) . The goal of these 
environments is to provide support for the definition 
of all the policies that makes up the global security 
policy of an organization into one single platform, 
thus simplifying management and consistency main- 
tenance. 

Some of these environments provide mechanisms to 
solve potential conflicts between contradictory poli- 
cies. Some of these mechanisms use special ad-hoc 
rules to decide upon the acceptability of an action 
whenever a conflict arises JlT|| ; others use properties 
such as "authorship", "specificity" and "recency" of 
security policies to decide on their priority ||, 
or combine policies through special operators which 
decide on the policies' applicability Jl3[ . 

These mechanisms are used to solve conflicts re- 
sulting from the existence of implicit rules in common 
language. For instance, a user specifies that all his 
files should not be read by any one else, and simul- 
taneously, he specifies that the files with information 
about a particular project should be accessible by 
all members of the project. This situation is not a 
conflict in common language since the second rule is 
obviously an exception to the first, but it may be a 
conflict within a formal security specification. 

However, these conflict solving mechanisms should 
not be used to solve real inconsistencies derived from 
unification of several policies from several sources. In 
fact, they can even be detrimental, because they can 
masquerade real inconsistencies and produce wrong 
results. 

Although conflicts between contradictory policies 



are the most important type of inconsistency that 
may be present in a global security policy, they are 
not the only ones. For instance, a policy may be 
completely overridden by another policy in such a 
way that the former policy is completely useless; or 
the combination of two or more policies may result 
in a policy that denies every action in the system. 

Furthermore, within an organization, it is not 
enough to verify the security policy self-consistency, 
it is also necessary to verify the consistency of the 
security policy with other specifications of the orga- 
nization. For instance, if an organization's workflow 
application requires access to some documents and 
the security policy forbids that access, then the se- 
curity policy is inconsistent with that workflow spec- 
ification, which may prevent the organization from 
working as expected. 

In fact, given the constraint nature of security poli- 
cies, any specification document of an organization 
which comprises one or more constraints, may be a 
source of inconsistencies. Thus, the search for se- 
curity policy inconsistencies does not have a closed 
solution valid for every organization and situation. 
Each organization may have different specifications 
with constraints and different interpretations of se- 
curity policy inconsistencies. 

This paper's contribution is twofold: First, we ad- 
dress the general problem of checking for security 
policy inconsistencies, whatever they are, on large 
complex policies; then we address the problem of 
finding inconsistencies between security policies and 
other specifications with constraints, namely work- 
flow specifications. Both problems are addressed 
within a novel approach comprising a tool developed 
by us (PCV - Policy Consistency Verifier), based on 
the CHR constraint language ||, which finds incon- 
sistencies within and between security policies and 
other specifications. 

The rest of the paper is organized as follows. We 
first briefly describe the CHR language. Then de- 
scribe the tool architecture. Sections || and ^ describe 
how security policy and workflow specifications are 
handled by the tool. Finally, in section |t] we briefly 
survey some related work, and in section ^ we con- 
clude the paper. 



2 Constraint Handling Rules 

CHR is a high-level language designed for writing 
user-defined constraint systems ||. CHR is es- 
sentially a committed-choice language consisting of 
guarded rules that rewrite constraints into simpler 
ones until they are solved. CHR rules are of two 
types: simplification rules and propagation rules. 
Simplification rules replace user-defined constraints 
by simpler ones. Propagation rules add new redun- 
dant constraints that may be necessary to do further 
simplifications. 



Constraint 

A < B , B > A <4> true \ A = B //Simplification rule 

Head Guard Body 

A < B, B < C =^ true A < C // Propagation rule 
X < Y \ X =£Y true. // Simpagation rule 



Figure 1: Example of CHR rules. 

A CHR rule consists of three parts: a head, a guard 
and a body (Figure |l|). Each part is a conjunction 
of constraints. There are two kinds of constraints, 
user-defined and built-in constraints. User-defined 
constraints are relations that must hold between one 
or more entities, which assume the form of predicates 
or operations over those entities (e.g. less(l,2) or 1 
< 2). Built-in constraints are simple constraints that 
can be directly solved by the underlying solver (e.g. 
A = B). 

A simplification rule works by replacing the con- 
straints in the rule's head by the constraints in the 
rule's body, provided the constraints in the rule's 
guard are true. A propagation rule adds the con- 
straints in the body but keeps the constraints in the 
head (Figure |l|) . Figure |l| shows also a third type of 
rule named "simpagation" . A "simpagation" rule is 
equivalent to a simplification rule with some of the 
heads repeated in the body. On a "simpagation" rule 
only the heads after the "\" sign are removed. 
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3 Overview of PCV 

Security policies can be seen as collections of con- 
straints more or less structured (depending on the 
security platform used) into complex rules and poli- 
cies. These constraints may be as simple as "A mid- 
dle manager cannot approve purchases over a spec- 
ified amount" , or they can be as complex as con- 
straints comprising forms of prohibition, permission 
or obligation of user actions. 

Given the constraint nature of security policies, 
the PCV verifier is a natural candidate to be im- 
plemented with a constraint language such as the 
CHR language. This approach simplifies tool con- 
struction and potentiates its extensibility to other 
inconsistency definitions. 

PCV is composed by five layers (Figure ||). The 
first layer is the CHR symbolic solver engine, which 
is the only layer not comprised of CHR rules. The 
second layer is composed by the rules which handle 
basic constraint predicates (e.g. A < B, a e G) and 
constitutes the verifier's kernel. The third layer con- 
tains the rules which comprise the knowledge on how 
to decompose the specific constraints placed by each 
type of specification (security, workflow), into basic 
constraints. The fourth layer contains rules resulting 
from the compilation of the different specifications 
(e.g. security policy specification, workflow specifi- 
cation). Finally, the fifth layer contains the verifier 
goals, with the definitions of the security inconsisten- 
cies being searched. 

The purpose of this layering approach is threefold: 
(i) it simplifies the handler design, because each type 
of constraints can be handled independently; (ii) it 
simplifies the proof of correctness, because each layer 
has no knowledge of the layers on top and see the 
constraints of lower layers as built-ins; (iii) it sim- 
plifies the addition of new specification handlers, by 
defining the rules required by each specification. 

Briefly, the process by which inconsistencies are 
found works as follows. First the constraints within 
each specification being verified are compiled into 
CHR rules. Second, the PCV verifier is invoked with 
the constraint goals comprising the inconsistency def- 
initions. These goals are successively decomposed 
into simpler constraints, by the rules generated by the 
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Figure 2: The consistency verifier architecture. 
CH stands for Constraint Handler, and CR stands 
for Constraint Rules 

compilers (fourth layer), and by the rules compris- 
ing the knowledge on each specification type (third 
layer), until they can be solved by the kernel rules. 

In the following sections we proceed by describing 
each of these layers. For the sake of simplicity, each 
of the third, fourth and fifth layers were split in two 
(Figure ||), separating the rules of each layer that 
handle security constraints from the rules that handle 
other constraints. 



4 Kernel rules 

The verifier's kernel rules are responsible for handling 
basic constraints, resulting from the application of 
simple operators to basic entities. 

Kernel rules are divided into two major groups: 
rules to handle order and equality operators (>, <, 
<, >, =, 7^); and rules to handle membership and set 
constraints (g, ^, U (union), n (meet), # (cardinal- 
ity), [] (index)). 

4.1 Order and equality rules 

The rules to handle order and equality constraints de- 
rive from the "minmax" handler proposed by ||] , aug- 
mented with optional temporal qualifiers but without 
the "min" and "max" constraints. 

A constraint may be timed or timeless. A timed 
constraint results from applying a temporal qualifier 
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to a timeless constraint (e.g. X < Y becomes X < 
Y at T) . Timed constraints, by opposition to timeless 
constraints, are only valid at an instant T. 

Knowing how to handle timed constraints is of ut- 
most importance for checking for security policy in- 
consistencies. Many security policies use the notion 
of time when specifying dependencies from past and 
future events. For instance, history-based policies 
like the Chinese Wall policy use the notion of time 
to allow access to an object only if the same user has 
not accessed another object in the same class of in- 
terest. Another example is given by obligation-based 
policies which use the notion of time to ensure that 
some action happens in the future H] , 

Hi, . . . , H n =>• G\Bl, , B m - 

derives 

' Hi at T, . . . , H n G\Bi at T, . . . , B m at T. 

2 " _1 < Hi,... ,H n atT => G\Bi at T, . . . , B m at T. 

HiatT,... , H n at T =*> G\Bi at T, . . . , B m at T. 
and 

Hi,... , H n G\B'i, . . . , B' m . 
derives 

' H n ,... \ H[ at T & G'\B'i at T, . . . , B' m at T. 
2 " _1 } H[,... \ H' n at T <=> G\B[ at T, . . . , B' m at T. 
[ H[ at T, . . . , H' n at T <S> G\B[ at T, . . . , B' m at T. 

Figure 3: Template rules to build timed propaga- 
tion and timed simplification rules from their timeless 
counterparts. 

The rules which handle timed constraints derive 
from the rules which handle timeless constraints in 
accordance with the templates in Figure |[ A timeless 
rule with n constraints in its head derive 2" — 1 timed 
rules, each with a different combination of timed and 
timeless heads. The template rules for timed simpli- 
fication rules are slightly different from the template 



rules for timed propagation rules. Timed simplifica- 
tion rules only remove timed constraints. The time- 
less constraints used to activate each rule are not re- 
moved to preserve the activation sequence of timeless 
rules and therefore maintain their correctness. 



Figure 4: Rules to handle timed equality, (at T) 
stands for an optional time qualification. Although 
strict CHR rules do not allow optional elements, they 
are used here to simplify the description. 

Although the rules generated by the application 
of the template rules of Figure || are sufficient to 
handle every timed constraint derived from a user- 
defined timeless constraint, they cannot handle the 
timed constraints derived from built-in timeless con- 
straints. While timeless-equality constraints are han- 
dled by the underlying built-in solver, the same is not 
true for timed-equality constraints (X=Y at T) which 
require rules such as the ones in Figure f|. These rules 
can be divided in two groups: the first is composed of 
simplification rules describing redundancies and con- 
flicts between timed equality constraints and other 
constraints; the second consists of propagation rules 
describing the transitivity properties between timed 
equality constraints and other constraints. 

4.2 Set and membership rules 

Set constraints are not handled as usual. Since the 
verifier is to be used primarily on non-instantiated 
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@ X- 
@ X- 
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■Y atT <H> ground(X), ground(Y)\X - Y. 
X atT O true. 

Y atT \ Y=X atT O true. 
YatT\ Y<X atT O X=fY \true. 
YatT\X<YatT -S> X=fY\true. 

Y at T, Y<X{at T) -S> fail. 

Y at T, X<Y(at T) <s> fail. 

Y at T, YjtX(at T) «• fail. 

Y at T, XjtY(at T) o fail. 



% Transitivity rules 
WithSolf @ X- 

WithSolf @ X= 

WithSolf a X- 

WithSclf @ X- 

WLessOrEqual® X- 
WLessOrEqual® X= 
WLessOrEqual® X= 
WLessOrEqual® X- 



Y at T, 

Y at T, 

Y at T, 

Y at T, 

Y at T, 

Y at T, 

Y at T, 

Y at T, 



X=Z atT =4 
Y=Z atT => 
Z=X atT =i 
Z=Y atT => 
X<Z(atT) 
Y<Z(atT) : 
Z<X{atT) 
Z<Y(atT) : 



XjY^Z\Y=Z atT. 
X jY=£Z\X=Z at T. 
X=£Y^Z\Y=Z at T. 
XJY^Z\X=Z atT. 

> X=£Y=£Z\Y<Z atT. 

> X^Y^Z\X<Z at T. 

> X^Y^Z\Z<Y atT. 

> X^Y^Z\Z<X at T. 
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tautology 




A t Or, A £ Cr =S* jail. 


identity 


@ 


C = AnA^C = A. 


commutativity @ 


C = AnB\C=BnAo true. 


distributivity 


@ 


x e c,c = An b => A b\x e A, x e b. 


revDist 


@ 


x e A,X e B,C = An B A # B\X e c. 


rcvNotDist 


@ 


Xi£A,C = AnB=>X£C. 


rcvNotDist 


@ 


X^B,C = AnB^X^C. 


notDistrib 


@ 


X£C,XeA,C = AnB=>X£B. 


notDistrib 


@ 


X <£ C,X e B,C = An B X $ A. 


revDist 


@ 


labeling.X £ A, C = A n B => A B\ 






{(X £ B, X £ C); (X e C, X e B)). 


revDist 


@ 


labeling. XeB.C = AnB^A=jtB\ 






{(X <£ A, X <£ C); {X e A, X £ C)). 


notDistrib 


@ 


labeling, X <£ C, C = A n B =!> A ji B\ 






(X £ A: X $ B). 



Figure 5: Basic rules for membership and meet con- 
straints. 

specifications, when most sets are yet undefined - 
in the sense that their members are not yet known- 
it is not possible to directly solve in order to their 
contents. Instead of solving set constraints, we use 
them to derive membership constraints which can be 
directly solved. For instance, using the "distributiv- 
ity" rule, followed by the "tautology" rule of Figure 
[| the goal (C = A n B, X e C, X <£ B) leads to a fail 
state. 

Membership constraints may also be time-qualified 
such as order constraints. The CHR rules to han- 
dle such constraints are also derived from the tem- 
plate rules of Figure |^ but applied to the CHR 
rules which handle timeless membership constraints. 
Timed membership constraints are very useful when 
sets' contents are dynamic, which happens to be fre- 
quent in security policies, e.g. a user may have been 
playing a role and now he is playing another. On 
the other hand we do not provide rules to handle 
timed set constraints, since most relations between 
sets used in security policies (e.g. C = An B) are 
fixed during the whole policy lifetime. 

The last three rules of figure || contain disjunctions 
in their bodies (the ';' stands for built-in disjunction), 
which must be handled by test and backtracking. In 
order to improve efficiency these rules should be de- 
layed until there are no more constraints in the goal 
to simplify. The special labeling constraint is the last 
constraint in the goal to be solved. Thus, using this 



constraint in the head of rules ensures that they are 
activated only when all other constraints have been 
already simplified. 

Without further assumptions the program com- 
posed by the rules in Figure || does not terminate, be- 
cause the constraints generated by propagation rules, 
may be used to generate other constraints which are 
going to enable again the same rules. For instance, 
the constraints derived by the "distributivity" rule 
could be used by the "revDist" rule to derive the 
constraint X £ C, which may be used again to fire 
the "distributivity" rule. 

However, it is possible to ensure the program ter- 
mination under three new assumptions: 

• The CHR solver verifies the constraint store, be- 
fore introducing new constraints, to prevent the 
existence of multiple copies of the same con- 
straint in the constraint store^. 

• Membership constraints are never removed from 
the constraint store. 

• Meet constraints cannot be added to the con- 
straint store, by any program's rule. 

Under the first assumption the number of mem- 
bership constraints in the goal store is bounded, pro- 
vided that the number of variables in the initial goal 
store is bounded, and that none of the rules derives 
constraints with new variables. The second assump- 
tion is necessary to ensure monotonicity of member- 
ship constraints in the constraint store. The third 
assumption is necessary to ensure monotonicity and 
boundedness of meet constraints in the constraint 
store. 

The rules in Figure ^| are used to solve constraints 
using the restriction operand(:). The restriction 
operand is a binary operand between a set and a 
boolean function. The operation defines a new set 
comprised by all the members of the first set which 
satisfy the boolean function. The strategy followed 
by these rules is the same as the one followed by 
the rules to handle meet constraints (Figure |). The 

^^Most CHR solvers can be instructed to perform this check 
by enabling the "already _in_store" option. 
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idempotent @ C = A : \ D = A : R(_) •» C = D. 

restriction @ X e C, C = A : R(X),X e A. 

revRostric @ labeling, X £ A, C = A : H()=S" 

£ C);(X g C,-.i?(X))). 

Figure 6: Rules for set restriction constraints. The 
constraint C = A : R is a short form for C = {x G 
A : R(x)} where C and A are sets and R is a boolean 
function over x 

restriction constraints are used together with mem- 
bership constraints to derive other membership con- 
straints, and the rules containing disjunctions are de- 
layed until the end of the simplification process. 



Figure 7: Rules to handle cardinality constraints. 
The cardinality of set S is denoted by \S\. 

The rules to handle cardinality constraints (Figure 
0) may be divided into three groups. The first group 
is used to derive inequality constraints between car- 
dinality values of sets related by meet, union and re- 
striction constraints. The second group is composed 
of only one rule and is used to translate a cardinality 
constraint on a defined set into the built-in predicate 
length. This rule is used only if the set is completely 
defined, in the sense that all its members are known. 
However, as explained before, most sets are not com- 
pletely defined at verification time, which makes it 



impossible to know their cardinality. The third group 
of rules is used to verify if at the end of the verifica- 
tion process, the number of elements known to be in a 
set, over which a upper bound cardinality constraint 
exists does not exceed that upper bound. 

5 Security Rules 

As described in section || the rules which handle spe- 
cific security constraints are divided into three related 
layers: the security constraint handler; the security 
policy rules resulting from the compilation of the se- 
curity specification; and the consistency definition 
goals. Each of these layers is dependent on the pre- 
ceding and following layer and all are dependent on 
the specificities of the security policy definition envi- 
ronment. The security policy definition environment 
used in the current prototype is the Security Policy 
Language (SPL) O]. This security language was de- 
veloped by us with the purpose of specifying security 
controls for complex environments where several se- 
curity policies must be enabled simultaneously. 

In the remaining of this section we briefly describe 
SPL. Then we describe how the security CH handles 
the types of constraints placed by SPL. Finally, we 
describe the process of compiling SPL to CHR using 
the rules provided by the security CH. 

5.1 SPL 

SPL is a security language designed to express poli- 
cies to decide about events' acceptability. An event's 
acceptability depends on the properties of the event 
(e.g. author, target and action), on the context 
at that time and on the properties of past and fu- 
ture events. SPL entities are typed entities with an 
explicit interface by which their properties can be 
queried. Some of the entities manipulated by SPL 
are internal, such as rules and policies, but most are 
external, like users, files, actions, objects and events. 
The properties of each external entity depends heav- 
ily on the platform (operating system, workflow en- 
gine) implementing it. 

The language is organized in a hierarchical delega- 
tion tree of security policies, in which the master pol- 



% Relation with other set constraints 

identity @ ./VI — \L\ \ N2 = \L\ => Nl = N2. 

meet @ NC = \C\,NA = \A\, C = A n B => NC < N A. 

meet @ NC = \C\, NB = \B\, C = A n B =S- NC < NB. 

join @ NC = jej, NA = \A\, C = A U B NA < NC. 

join @ NC = \C\,NB = \B\,C = iUB=> NB < NC. 

restrict @ NA = \A\,NC = \C\, C = A : R => NC < NA. 

less N = \A\ integer(N), N < fail. 

% For defined sets. Sets with a specific length. 
eqSetMin @ N = \L\ => isJist(L)\ length(L, N). 

% For undefined sets. Sets without a specific length, 
insert @ X S L, N = \L\ ->isJist(L)\ member(X, L). 
eqSetMin @ labeling, N = \L\ 

-lis Jist(L), integer (N), N > 0| 

cardinal(L, N). 
lesser @ labeling, N = |i|, N < Nl =>• 

-lis J,ist{L), integer {N I), Nl > 0| 

cardinal(L, Nl). 
lesseq @ labeling, N = \L\, N < Nl 

-lis Jist(L), integer {Nl), Nl > 0| 

cardinal(L, Nl). 
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icy is the root delegation starting point. A SPL pol- 
icy is a structure composed by sets and rules, whose 
purpose is to express simple concepts like "separa- 
tion of duty" , "information flow" , or "general access 
control" . 

Sets contain the entities used by the policies to 
decide on event acceptability. A SPL rule is a func- 
tion of events that can assume three values: "allow" , 
"deny" and "notapply". It's purpose is to decide on 
the acceptability of the current event. A rule can be 
simple or composed. A simple SPL rule is a tuple 
of two logical expressions. The first logical expres- 
sion decides on the applicability of the rule, and the 
second decides on the acceptability of the event. 

A SPL rule can be composed by other SPL rules 
through a specific tri-value algebra with five logic 
operations: conjunction (AND); disjunction (OR); 
negation (NOT) ; existential quantification (EXIST x 
IN set rule); and universal quantification (FORALL 
x IN set rule). These operations behave similarly to 
their binary homonyms if the "notapply" value is not 
used and the "allow" and "deny" values are used as 
true and false, respectively. 

Each policy has one special SPL rule called the 
"query rule" which is identified by a query mark be- 
fore the name that defines the policy behavior. 



policy Privatef user set OrgUsers ) { 


object set IDocs; 


/ / Policy data 


?Privatc: 


/ / Rule name. 


event. action — "SendEmail" £ 


c If Applicability 


event. target IN IDocs 


/ / expression. 




/ / Separation marker. 


event. par[l] IN OrgUsers 


/ / Aceptability 


} 


/ / expression. 



Figure 8: Simple policy stating that objects belong- 
ing to IDocs can only be sent to users belonging to 
OrgUsers. 



Figure || shows a simple policy stating that docu- 
ments internal to the entity defining the policy can- 
not be sent to someone outside the organization. The 
policy has two sets and one SPL rule: the query rule. 
One of the sets is a policy parameter and contains the 
users that belong to the organization. The other is 
internal to the policy and contains the department's 
internal documents. The rule uses the special vari- 



able "ce" to access the current event properties. The 
rule's applicability expression states that the policy 
is defined only for events whose targets are depart- 
ment's internal documents internal and whose action 
is to send an e-mail. The rule's acceptability expres- 
sion states that for those events that satisfy the ap- 
plicability expression the only allowed events are the 
ones that send the e-mail to a user of the organiza- 
tion. 

5.2 Security Constraint Handler 

Although most SPL constraints can be handled di- 
rectly by the verifier's kernel rules, some cannot. For 
instance, the constraints resulting from the logical 
negation of other constraints, or the constraints re- 
sulting from using the SPL tri-logical operators over 
SPL rules, require some additional rules in order to 
be solved. 



Figure 9: Rules to handle logical constraints. The 
symbol V stands for exclusive disjunction. 

Handling logical negation is straightforward, pro- 
vided that the verifier also handles logical constraint 
conjunction and disjunction. The rules which handle 
these constraints are shown in Figure |[ To simplify 
SPL to CHR compilation we also provide some rules 
to handle exclusive disjunction over constraints. 

Although logical constraint conjunction and dis- 
junction are handled by direct translation to their 



comutativity 


@AAB\B/\Ao true. 


comutativity @AVB\JJV/1» true. 


comutativity @AvB\BvA» true. 


definition 


@ labeling AjtB\(A; B). 


definition 


6AAB# A=£B\A,B. 


definition 


@ A<j B o AjtB\{A A -■B) V (-.A A B). 


identity 


@ A A A A. 


identity 


<§• A V A A. 


irrcflexivity 


iiVJ« fail. 


tautology 


@ -itrtte -S> fail. 


tautology 


@ -./aiZ true. 


tautology 


<3> -,(-,A) -S- A. 


dcMorgan 


<§• -•(A AB)# (negA V negB). 


deMorgan 


@ -,(A VB)« -iA, -iB. 


definiton 


e^(AvB)»(AAB)V (^A A -.S). 


reduction 


@ -•(A < B(atT)) B < A(atT). 
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built-in counterparts (by the "definition" rules) , their 
negations are handled by the DeMorgan rules, thus 
pushing negations to basic kernel constraints where 
they can be handled by the "reduction" rules. 



definition 


@ R = 


= not r(D, A) «-> i? = r(D, -.A). 


commutativity @ R3 = Rl and R.2 \ RA = R.2 and Rl R4 = R3 


identity 


@ R3 


= _R1 and_Rl _R3 = Rl. 


neutral 


® R3 


= r(/oii, X) zndR2 •£> A3 = R2. 


neutral 


@ R3 


= Rl andr(fail, X) 4$ R3 = Rl. 


absorb 


@ R3 


= r{true, fail) and .R2 <^> i?3 — r(triAe, fail) . 


absorb 


@ R3 


— andr(frue, fail) 4> H3 — r(iriie, fail). 


default 


@ -R3 


= r (true, true) and r(D2, A2) 4> 






H3 = r(true, ^D2 V A2). 


default 


@ A3 


— r(Dl, Al)and ritrue, true) 4> 






R3 = r(true, -.Dl V Al). 


definition @ R3 


= r(Dl, Al) andi-(D2, A2) 




H3 


= r(Bl V _D2, (-.Dl V Al) A (^D2 V A2)). 



Figure 10: Rules to handle SPL's tri-logical conjunc- 
tion and negation. 



The rules that handle constraints resulting from 
applying SPL tri-logical operators to SPL rules are 
straightforward. Most of these rules are just trans- 
lations of each operator's definition (Figure For 
instance, the tri-logical conjunction of two SPL rules 
defined by the predicates r(Dl,Al) and r(D2,A2), 
in which Dl and D2 stand for the domain expres- 
sions of each of the rules and Al and A2 stand for 
the acceptability expressions, is simplified to another 
SPL rule defined by the predicate r(Dl VD2, KD1 V 
Al) A (-.D2 V A2)) (definition rule in Figure [h]). 

The remaining rules reflect special situations in 
which the result is known without the need to eval- 
uate the definition. For instance, the result of a tri- 
logical conjunction between two SPL rules in which 
one of them has an empty domain is equal to the 
other rule (R and r(fail, A) is R). 

SPL tri-logical quantifiers are slightly more com- 
plex to handle. Figure |ll| shows the rules to han- 
dle the universal quantifier forall(5ei, Tr, R) at T, 
which should be read as R — {V x G Set at T : Tr(x)}. 
The rules are divided into two sets: the rules that 
handle universal quantifiers over defined sets; and 
the rules that handle universal quantifiers over sets 
defined by membership constraints. 

Both sets of rules handle the quantifiers constraints 
by unfolding them to n tri-logical conjunctions. How- 



% Quantification over proper sets 


empty ^ 


S forall(Set, TR, fl)atT«. isJist(Set), Set = []| 




R — r(fail, true). 


forEach (! 


i forall(Set,Tfi, R) at T <H- isJist(Set), 




Set = [X\Tail]\R= csllTR(X),R = RlandR.2, 




f orall(Taii, TR, R2) at T. 


% Quantification over undefined sets 


convert £ 


8 forall(Set, Tr, B) at T «• ^is.list(Set)\ 




f orall(Set, Tr, R, []) at T. 


insert ^ 


S X £ Set at T \ f orall(Set, Tr, R, U) at T 




not-member(X, U)\R = Tr{X) zndR2, 




forall(Set, Tr, R2, [X\U]) at T. 


insert ^ 


i X £ Set \ f orall(Set, Tr, R, U) at T 4> 




not_memher(X, = Tr(X) and_R2, 




forall(Set, Tr, R2, [X\U]) at T. 


no_moreQ labeling \ f orall(Set, Tr, R, U) at T <S> 




_R — r(fail, true). 



Figure 11: Rules to handle SPL's tri-logical universal 
operator. 



ever, the rules that handle quantifiers over undefined 
sets require an extra constraint property to account 
for the membership constraints which have already 
been used with each quantification constraint (Fig- 
ure [ll]). This account is necessary to prevent non- 
termination caused by using each membership con- 
straint more than once with each quantification con- 
straint. 

The rules to handle existential quantifier con- 
straints are very similar to the ones that handle uni- 
versal quantifier constraints. The difference is that 
existential quantifiers are unfolded to tri-logical dis- 
junctions. 

5.3 Compiling SPL 

For the purpose of consistency verification, SPL poli- 
cies should be seen as operator definitions, which are 
used to state event constraints. The goal of the SPL 
compiler is to generate the rules necessary to handle 
each of these types of constraints. 

Since SPL is a constraint language, translating it 
into CHR is a direct process. Each policy is seen as a 
complex constraint composed by other simpler con- 
straints. Thus, each policy definition is translated 
into one simplification rule, with one user-defined 
constraint in the head, several constraints in the body 
and no guard. The constraint in the head is a predi- 
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cate with the policy's name, applied to a tuple with 
a SPL rule representing the policy, every explicit 
policy's parameters and four implicit ones: current 
event, global and local variables. The body of the rule 
is composed by one constraint for each SPL group or 
rule definition inside the policy. These constraints 
can then be further simplified by the rule of the con- 
sistency engine. 



private (.Event 


OrgUscrs, Locals, Globals, R) 




Event 


— event(Actor, Action, Target, Pars 


Time), 


Locals 


— locals(privatc_vars(IDocs)), 




R 


= r( Action = "SendMail" A Targ 


et £ IDocs, 




Pars[l] £ OrgUscrs). 





Figure 12: The figure shows the translation of the 
SPL policy of Figure | to CHR. 



Figure [l2] shows the translation of the SPL policy 
presented in figure ||. The policy is translated into a 
simplification rule with two constraints in the body. 
One of the constraints states that the set "IDocs" 
is defined inside the predicate "locals", in the "pri- 
vat_vars" section. The other states that the SPL rule 
to apply is defined by the predicate "r" applied to the 
tuple composed by the applicability and acceptability 
expressions. 

Although most policies can be translated into a 
single CHR rule, some require more than one rule, 
and some require special handling to increase per- 
formance. For instance, as referred in the previ- 
ous section, existential quantifiers are unfolded to 
tri-logical disjunctions of each of the quantification's 
elements, which in turn derive built-in disjunctions 
that may compromise performance due to backtrack- 
ing. In some situations, existential quantifiers are 
transformed into conjunctions of two constraints by 
a process known as Skolemization pQ| . This trans- 
formation is possible if the set of the quantification 
is not empty and the applicability expression of the 
SPL rule does not depend on the quantification vari- 
able. Under these conditions, the existential quan- 
tification "3 X € A : rule(x)" is equivalent to "c G A 
and rwZe(c)" where "c" is a Skolem constant. 



5.4 Security self-consistency 

A security policy may be inconsistent in several ways. 
For instance, a security policy which is never appli- 
cable is unnecessary, thus inconsistent. On the other 
hand, a security policy that denies every event is also 
inconsistent. Several other inconsistency definitions 
may be devised. Currently, our prototype is able to 
check four types of policy inconsistencies: 

• Inapplicability: the policy is never applicable; 

• Monotonic denial: the policy denies every event; 

• Monotonic acceptance: the policy accepts every 
event; 

• Rule redundancy: one or more rules in the policy 
are redundant. 

Verifying the first three types of inconsistency is 
straightforward. It is only necessary to find a solution 
for the event variable on each of the following goals: 

E e AllEvents, my Policy (E, .. . ,r(D,A)), D. 

E e AllEvents, myPolicy(E, ... , r(D, A)), -iD V A. 

E £ AllEvents, myPolicy(E, ... , r(D, A)), -lD V ->A. 

The fourth type is slightly more complex. Briefly, 
the verifier should replace, in turn, each of the rules 
to check for redundancy, by a dummy rule with an 
empty applicability domain, and check for differences 
between the original policy and the modified policy. 



commutativity @ Rl dif f R2 R2 dif f Rl <S> true. 
identity @ fldiff R <S> fail. 

definition @ r(Dl, Al) diff r{D2, A2) -S- 

(Dl V D2) V ((£>! A Al) <J(D2 A A2)). 



Figure 13: Rules to handle the diff operator. This 
operator restraints two SPL rules to be different 

The replacement of each rule by the dummy rule is 
done by the underlying platform. The actual test for 
policy differences is done by the diff operator (Fig- 
ure |l3|), which restraints the "query" rules of each 
policy to be different. If this constraint fails, this 
means that both the original and the modified poli- 
cies are equal and the replaced rule is redundant. 
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6 Workflow Rules 

Most specifications comprising constraints within an 
organization are eligible to be checked for consistency 
together with the organization security policy. The 
specific importance of workflow specifications results 
from being usually used all over the organization, po- 
tentially crossing different security management do- 
mains, thus increasing the probability of occurring 
inconsistencies. 

Although workflow specifications are usually cre- 
ated by a graphic tool, and kept inside a workflow 
framework in an internal format, several workflow 
frameworks also support the "Workflow Process De- 
scription Language" (WPDL) jOl for specification 
interchange purposes. Given the interchange purpose 
of WPDL we have found it to be the ideal language to 
test the verifier's ability to express and handle work- 
flow specifications. 

In this section we briefly describe WPDL. Then we 
describe how WPDL is translated into CHR, and why 
the workflow CH for WPDL is empty. Finally, we give 
some examples of cross-consistency goal definitions. 



to sequential or parallel activities execution. The in- 
formation related to split and join properties is de- 
fined within the appropriate activity. 

The join property decides if the activity requires 
the activation of only one or every incoming transi- 
tion. The split property decides if, after the activity 
is performed, every outgoing transition is activated 
or if only one of them is activated. In the latter case 
the activated transition is chosen from a priority list. 
If the first transition cannot be activated due to its 
activation condition, the next transition is chosen. 

Participants are resources that may be assigned to 
activities. A participant may be a person, a role, 
an application (automated activity), or an organiza- 
tional unit. 



Q A0 



Tl 



Participant = Manager 
Action = Submit Expense 
plit = only one: TO, Tl 

. From = AO 

From = AO 
To=A2 

Condition= otherwise 




To = Al 

Condition = Expense. cost < 1000 



CA2 Participant = Director 
I | Action = Aprove Expense 1 



Al I Participant = Manager 

Action = Approve Expense 



6.1 WPDL 

WPDL's main entities are: activities, participants 
and transitions. Each activity is a logical, self- 
contained unit of work within the workflow defini- 
tion, performed by a participant. An activity may be 
atomic, a sub-flow, loop activity or a dummy activity. 

Atomic activities are the ones which are going to 
be activated by events and therefore controlled by 
the security policy. A sub-flow activity is just a con- 
tainer for a sequence of activities. A loop activity is a 
special control activity comprising a loop condition. 
For each loop activity there are two special transi- 
tion entities pointing from and to it. The outgoing 
transition points to the loop's start activity. The in- 
coming transition points from the loop's end activ- 
ity. Dummy activities are used to support routing 
decisions within the incoming and/or the outgoing 
transitions. 

Transitions are comprised by three elementary 
properties: the from- activity, the to-activity, and the 
activation condition. Transitions execution may lead 



Figure 14: A workflow definition example: Ai stands 
for activity i and Ti stands for transition i. 



Figure 14 shows an example of a workflow defini- 
tion. "Activity 0" is performed by a Manager and is 
an expense submission. After being executed, "activ- 
ity 1" enables two transitions, but only one of them 
can be executed. It first tries "transition 0" , if the 
expense's cost is less than 1000 then "transition 0" 
is executed and "activity 1" becomes enabled, other- 
wise "transition 1" is executed and "activity 2" be- 
comes enabled. 

6.2 Compiling WPDL 

For the purpose of consistency verification, each 
WPDL activity specification is seen as the definition 
of a specific type of logical operator, to state event 
constraints. These constraints fail when the event is 
incompatible with the activity. For instance, when 
the author of the event is different from the partici- 
pant required by the activity. 
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Transitions may also be seen as logical event oper- 
ators. The purpose of these operators is to establish 
temporal constraints between events enacting the to- 
and the from- activities of the transition. 

The WPDL compiler generates the CHR rules for 
handling these constraints. However, due to the 
WPDL's simplicity it is not necessary to provide aux- 
iliary CHR rules, such as the ones comprising the se- 
curity constraint handler (section |5.2| ) . Thus the spe- 
cific workflow constraint handler for WPDL is empty. 



aO(E, Globals) <S> 

E = event(Actor, Action, Target, _,_), E £ AllEvcnts, 
Actor £ Clerk, Action — "Build", Target — Budget. 

al(E, Globals) tO(E, Globals), 

E = event(Actor, Action, Target, _,_), E £ AllEvcnts, 
Actor £ Clerk, Action — "Approve", Target — Budget. 

a2(E, Globals) tl(E, Globals), 

E = cvent(Actor, Action, Target, _,_), E £ AllEvents, 
Actor £ Boss, Action — "Approve", Target — Budget. 

tO_test(E, Globals) <S> Budget = budget(Cost), Cost < 1000. 
tO(E, Globals) <S> t0.test(E, Globals) , aO(PreviousE, Globals), 
E = cvcnt(_,_,_,_, T), E £ AllEvents, 

PrcviousE — cvent(_,_,_,_, PrcviousT), PrcviousT < T. 

tl.test(E, Globals) <S> -i t0.test(E, Globals). 
tl(E, Globals) <S> tl.test(E, Globals), aO(PreviousE, Globals), 
E = cvcnt(_,_,_,_, T), E £ AllEvents, 

PreviousE — event(_,_,_,_, PreviousT), PrcviousT < T. 



Figure 15: This figure shows the translation of the 
workflow of Figure [l| to CHR. AllEvents, Clerk, 
Budget and Boss variables are defined within Globals 
(not shown for simplicity) 

Figure [l5] shows the rules resulting from the compi- 
lation of the workflow definition of Figure 14, Activ- 



ity constraints are simplified to conjunctions of basic 
constraints on event properties and of transition con- 
straints. 

Transition constraints are simplified to basic con- 
straints and activity constraints. The actual con- 
straint simplification of transition constraints is di- 
vided into two simplification rules, to assist in ex- 
pressing dependency on other transitions, when they 
are in the same split priority list. For instance, the 
constraints of type tl depend on the failure of the 
test condition of constraints of type tO. 



6.3 Workflow/Security consistency 

A workflow specification may be inconsistent with a 
security policy in several ways. For instance, a work- 
flow may be inconsistent if at least one of its activities 
cannot be executed under the security policy. It may 
also be inconsistent if there is no activation path be- 
tween its start activity and its end activity allowed 
by the security policy. 

The last situation is particularly interesting since 
it reflects the impossibility of performing the work 
for which the workflow was conceived. To verify this 
inconsistency it is only necessary to find a solution 
for the event variable E which satisfies the goal: 

E G AllEvents, last Activity (E, . . . ), 

forall(All Events, Tr(. ..),R). 

where 

Tr(E, . . . ,R) h master Policy (E,. . . , R),close(R). 

The first line of the above goal states that there 
is an event, belonging to the events set, which satis- 
fies the last activity constraints. Since, by definition, 
the last activity implies the existence of an event for 
each of the preceding activities, the goal states the 
existence of an event for each activity from the start 
activity to the end activity. The second line of the 
consistency goal states that every event must also 
satisfy the security policy, thus stating consistency 
between the two specifications. 

The "close" constraint is an auxiliary constraint 
which specifies the behaviour of the security service 
when a security policy does not apply to an event. 
With the close assumption, the service denies those 
events. With the open assumption, the service allows 
those events. The rules to handle the "close" and 
"open" constraints are defined as: 

open r(Dl, Al) <S> -iDl V (Dl A Al). 

close r(Dl, Al) ^ Dl A Al. 

These rules have another important function. 
They act as the bridge between the tri-value logic 
used by the security constraints and the binary logic 
used by the workflow constraints. 

Although we have not exhaustively tested with 
many different inconsistency types, the results we 
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have obtained so far and the flexibility of the under- 
lying platform, lead us to believe that PCV is able to 
find most types of inconsistencies within and between 
security policies and other specifications. 

7 Related work 

The security inconsistency problem has been ad- 
dressed by many authors. Some solve conflicts within 
security specifications by adding implicit rules to in- 
complete specifications jy], ||, [T2J . Others detect in- 
consistencies in security properties within workflow 
specifications || EL 

Jajodia et al nTl define a logical language with 
ten predicate symbols to express security policies. 
Three of them are authorization predicates (der- 
cando, cando, do), used to define the allowed ac- 
tions. Although not explicitly, these predicates de- 
fine three authorization levels with "dercando" as the 
weakest and "do" as the strongest. The "do" pred- 
icates are used to solve conflicts between "cando" 
predicates, "dercando" predicates are derived from 
"cando" predicates, and are overridden by "cando" 
predicates when in conflict. 

Another approach to conflict resolution, presented 
in H and uses elements such as rule authorship 
authority, rule specificity and rule recency to prior- 
itize rules. Although simple and natural, this ap- 
proach may lead to undesired behavior. It is not un- 
common for a high authority manager to issue a rule 
which may be overridden by a low authority man- 
ager, or to express a mandatory general rule which 
should not be overridden. 

Bertino et al |jj also use constraints to detect in- 
consistencies of roles assignment to workflow tasks, 
and to plan effective inconsistent-free role assign- 
ments. Although the work is able to model several 
types of restrictions on role assignment, namely sev- 
eral forms of separation of duty, it does not consider 
any other kind of security or workflow restrictions. 

Atluri and Huang Q use a different approach to 
detect inconsistencies between security and workflow 
specifications. They model security and workflow 
restrictions as Petri nets, and state that the safety 
problem in the authorization model is equivalent to 



the reachability problem in that type of nets. They 
assume a model where authorization restrictions are 
the subset of workflow restrictions that specify users 
and roles authorizations. 

However, to our knowledge, the general problem of 
inconsistency detection on complex security policies, 
comprising several types of inconsistency, including 
inconsistencies with other specifications, has never 
been addressed by any author. 

8 Conclusions 

We have defined a tool (PCV) to detect inconsis- 
tencies within security policies and between secu- 
rity policies and workflow specifications. PCV is 
able to detect several inconsistency types within se- 
curity policies defined with the SPL language, which 
is able to express complex security polices, and be- 
tween those security policies and WPDL workflow 
specifications. 

PCV is easily adapted to each organization's needs 
by allowing the definition of other inconsistency types 
and target specifications. 

Currently, our prototype has approximately 300 
CHR rules running over the CHR solver provided 
with SICstus Prolog j|, and is able to handle all 
SPL and WPDL constraints. Some experiences have 
been performed using compositions of SPL policies 
and workflow specifications to validate the process. 
Namely, we have tested several workflow specifica- 
tions with security policies comprising separation 
duty, information flow, and other types of security 
policies, with promising results. 

This work is part of a security platform which also 
includes a security language able to simultaneously 
express several complex security policies -the SPL 
language- and a compiler which is able to enforce it 
efficiently within an event monitor service. 
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